문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 언리얼 엔진/역사 (문단 편집) ==== 정적인 라이팅 ==== Q. 라이팅(Lighting)이 정적이며 동적 라이팅에 약한가? 결론부터 말하자면 이 또한 사실이 아니다. 언리얼 엔진 3는 정적 라이팅뿐만 아니라 동적 라이팅도 완벽 지원하며 실시간 풀 다이내믹 라이트로 모든 환경을 구성할 수도 있다. 따라서 맵 제작 시에 각각의 라이트에 대해 동적 라이팅으로 구성할지, 정적 라이팅으로 구성할지에 대한 옵션이 존재한다. 한다면 맵 전체에서 정적 라이팅을 강제로 완전히 제거하고 동적 라이팅만을 사용하는 옵션도 있다. 언리얼 엔진 3는 기본적으로 3가지 타입의 라이팅이 존재한다. 라이트맵을 만들어내는 기본 라이트 액터, 그리고 각 라이트 액터를 완전 실시간 라이팅, 섀도로 구현하는 무버블 라이트 액터, 그리고 각각의 라이트 액터를 섀도맵과 함께 토글할 수 있는 토글러블 액터 이렇게 3가지가 있다. 그와 더불어 주변의 라이트를 뭉뚱그려 연산을 최소화하여 동적 오브젝트에 적용하는 기법이 적용되어 있는데, 이 기술 역시 언리얼 엔진 1부터 사용돼 오던, 오래전부터 있던 기술이고 다른 엔진을 사용한 게임에서도 흔히 사용되던 기술인데, 언리얼 엔진 3에서는 이 기술을 각별히 여러 가지 용도로 최적화하여 툴에서도 용도에 맞게 사용 가능하도록, 그리고 쉽게 에디터상에서 껐다 켰다 할 수 있도록 구성해 놓았으며, 이것을 Light Environment라고 부른다. Light Environment는 오브젝트에 적용 가능한 주변의 라이트를 뭉뚱그려 라이트의 밝기, 방향성 같은 여러 요소들을 단 하나로 통일한 후 일정 크기의 라이트 존을 만들고 그 존에 들어간 오브젝트는 뭉뚱그려 넣어진 라이트의 성질로만 반응한다. 그렇게 함으로써 실시간 라이트를 적용하여 그럴듯한 연출을 보여주면서도 연산량을 대폭 줄일 수 있는 것이다. 하지만 이것이 때로는 주변의 배경과 맞지 않는 매우 부자연스러운 모습을 보일 수 있다. 그리고 이 반응 속도에는 Tick이라는 시간을 정할 수 있는 기능이 있는데 Tick의 주기가 길면 길수록 실시간으로 체크하는 부분이 느슨해지기 때문에 연산량이 확~ 줄어들지만 라이팅에 대한 반응 속도가 그만큼 늦어져 오브젝트가 해당 존에 들어간 지 길면 약 1초 후에 오브젝트의 라이트 반응이 나타난다. 이 반응 속도 또한 퍼포먼스와 비례한다. 따라서 적절히 게임플레이 시 눈에 잘 띄지 않는 부분을 선별하여 사용하는 게 중요하다. 그럼에도 불구하고 게임을 오래 하다 보면 발견할 수 있는데, 이 부분 때문에 언리얼 엔진 3가 동적 라이팅에 약하고 배경과 캐릭터의 라이트의 적용이 다르다는 오해를 낳기도 했다. 완전 실시간 동적 라이트를 사용하는 것은 매우 쉬운 일이다. 단지 맵 전체에서 라이트맵을 끄고, 모든 라이트를 무버블 라이트로 사용하며, Light Environment도 끄고, 실시간 섀도를 적용하면 그만이다. 하지만 그렇게 하기엔 연산량이 매우 많아져서 퍼포먼스 저하가 급격하게 이루어지기 때문에 대부분의 경우 그렇게 사용하는 게임은 거의 없다. 그렇게 구성된 게임은 [[둠 3]]나 [[시프: 데들리 섀도스]] 같은 게임들에 국한된다. 이 게임들은 모두 맵이 어둡고 좁은 실내 위주로 구성되어 있으며 한 화면에 등장하는 라이트의 개수는 매우 제한적이다. [[크라이엔진]]의 경우도 라이트맵이 없고 실시간 라이트로만 맵이 구성되지만 이 경우엔 단 하나의 디렉셔널 라이트에 의존하는 방식이라 그 한계가 명확하다. 2009년 이후 동적 라이팅에 대해 디퍼드 렌더링이라는 기법이 널리 사용되면서 다수의 동적 라이팅을 비교적 퍼포먼스의 큰 저하 없이 사용할 수 있게 되었는데, 이 기술은 동적 라이팅 연산이 행해지는 시점을 신의 메시가 렌더링이 완료된 이후로 이루어 놓고 연산하는 것으로, 라이팅 연산을 마치 후처리 효과처럼 구현하는 것이라 퍼포먼스의 저하는 훨씬 덜 하여 Light Environment나 라이트맵, 토글러블 라이트 같은 것을 줄이고도 실시간 라이트를 한 화면에 수십 개 사용하고도 비교적 저사양으로 구동이 가능하다. 하지만 라이팅 연산이 모든 신의 메시가 렌더링된 이후에 라이팅의 연산이 행해지는 구현기법의 한계상 반투명 오브젝트나 SSS를 사용한 표면 같은 부분에는 적용이 제한되기에 동일한 장면에서도 각각의 부분별로 디퍼드 렌더링으로 구현된 라이트와 일반 라이트를 적절하게 섞어서 사용해야 하는 꼼수가 필요하다. 그리고 디퍼드 렌더링으로 구현되는 동적 라이팅은 라이트만 기존의 연산에 비해 후처리 연산처럼 적용되어 연산량이 줄어드는 것이지 거기서 파생되는 그림자는 그전부터 이미 후처리 방식으로 생성되는 것이기 때문에 디퍼드 렌더링으로 만든 라이트를 수십 개 놓은 후에 그 라이트 하나하나에 실시간 그림자를 전부 놓은 것은 급격한 퍼포먼스 저하를 일으키는 한계도 존재한다. 이 디퍼드 렌더링은 언리얼 엔진 3에도 버전업이 되면서 적용되었다. 언리얼 엔진 3의 초기 버전인 1xx(2004년 3월)부터 최종 버전인 12791(2015년 2월)까지의 기간을 보면 언리얼 엔진 1(1996년) 언리얼 엔진 2(2001년)에 비해 언리얼 엔진 3에서 언리얼 엔진 4까지의 주기가 매우 길다는 것을 알 수 있다. 이는 [[UDK]]가 공개되면서 수많은 사용자들에게 피드백을 받고 개선 사항을 적용함으로써 엔진의 버전업이 더욱 가속화되었기에 세대별 주기는 길어졌지만 세부 버전 넘버의 변화만큼 실제 엔진의 기능과 성능적인 면이나 툴에서는 매우 많은 변화가 있다. 언리얼 엔진 2.5의 최종 빌드인 3369와 언리얼 엔진 3의 초기 버전 1xx의 차이보다 언리얼 엔진 3 초기 버전 1xx와 언리얼 엔진 3 후기 빌드 1xxxx대의 차이가 훨씬 더 많다는 것이다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기